Skip to content

Skip breakable props bots cannot start clearing - #2208

Closed
sunzenshen wants to merge 1 commit into
NeotokyoRebuild:masterfrom
sunzenshen:bot-clear-breakable-prop
Closed

sunzenshen wants to merge 1 commit into
NeotokyoRebuild:masterfrom
sunzenshen:bot-clear-breakable-prop

Conversation

@sunzenshen

@sunzenshen sunzenshen commented Oct 8, 2026 •

Copy link
Copy Markdown
Contributor

Description

What it does

A bot clears a breakable in its path with CNEOBotPathClearBreakable. GetBreakableInPath accepts anything
IsAbleToBreak() names, which includes breakable props (CBreakableProp: prop_physics, prop_physics_multiplayer),
but Update ends the action with "Path is clear" on a target that is not IsAlive(), and CBaseProp::IsAlive() is
always false. So on a prop in the path the action started, switched to the knife or secondary, ended on its first
update and switched back, and the tactical monitor started it again on the next update: a start/end cycle about
every 0.13 s while the bot walked on, pushing the prop.

This PR starts the action only on a breakable that passes the same intact test Update uses (one helper,
IsBreakableIntact, now used by both). func_breakable and func_breakable_surf never leave LIFE_ALIVE, so they
pass it as before.

Dependencies and status

Needs (code PRs this one depends on):

Helped by:

  • None.

Pending before review:

Navmesh PRs that rely on this

None. Its screen includes ntre_rise_ctg (stuck 8.2 -> 4.5 a match, a small sample), whose navmesh PR NeotokyoRebuild/neoAssets#160 does not wait on it.

How to test

  1. Build, start a match with bots on a map with physics props on their routes (ntre_marketa_ctg, ntre_transit_ctg).
  2. Watch a bot walk into a crate or barrel: before, it switches weapons back and forth several times a second while
    it pushes the prop; now it keeps its weapon.
  3. Watch a bot reach a glass pane or func_breakable in its path: it still switches weapon and breaks it.

Risk

Breakable props never start this action now. Instead the bot keeps following its path: the bot locomotion counts
any breakable as traversable (CNEOBotLocomotion::IsEntityTraversable), so it walks into the prop and pushes it, as
it already did between the cycles. Bots never knifed a prop out of the way before either, since the action never
lasted past its first update on one. A prop the bot cannot push aside stays a stuck spot, as before (one on marketa's
upper walkway, below). Glass and func_breakable are unchanged.

Cost

An IsAlive() and a GetHealth() call on the hull trace's hit entity, only when it is a breakable. Near props it
removes a suspend, a weapon switch and a resume per update.

Results

Debug dedicated server, CTG, 30 bots, ghost spawn pinned, 1 round, the same harness-only telemetry in both builds.
Both builds are #2207's branch (it changes only when a ghost carrier with an enemy in sight may start this action),
without and with this change. The cycle is on master too: in #2207's own screen, master's ghost carriers alone
started it 53 times with no enemy in sight. A cycle below is an action that ended within 0.3 s with its target
intact. ntre_marketa_ctg runs the navmesh of NeotokyoRebuild/neoAssets#159 with dead links cut.

  • Marketa, ghost spawns 10 and 19, 4 matches a build: 236 cycles before (prop_physics_multiplayer 162,
    prop_physics 74), 0 with the change. Glass panes still broken: 6 of 6 starts before, 1 of 1 after.
  • Screen, 48 matches a build (marketa 20 ghost spawns, transit, rise, dusk 5 spawns x 2): 1447 cycles before, all
    but 2 on props (the 2 were glass and a func_breakable, ended by an enemy in sight), 0 with the change. Action
    starts 1504 v 76; panes and func_breakables broken 54 v 67.
  • Stuck events a match, before v after, 95 % intervals overlapping on every map: dusk 17.9 v 13.7, transit 11.5 v
    9.4, marketa 10.1 v 8.3, rise 8.2 v 4.5. Kills a match 24.7-26.0 v 22.6-25.9 (dusk 24.7 v 22.6, n=10): the change
    only removes weapon swaps near props, so no mechanism for fewer kills was found; read as variance. Ghost
    captures 2 v 3 of 48. 96 of 96 matches ended on their own, no asserts.

Known, not changed: on marketa's upper walkway (754,1295,215) bots stall against a prop_physics_multiplayer in both
builds (2.5 v 2.2 stuck events a match): before inside the cycle, after in their normal seek behavior.

Not done here: letting the action run on props (an intact test that does not use IsAlive()), so bots knife crates
in their way. That would stop a bot at each breakable crate on its route, for up to the action's 10 s give-up time,
where it now pushes the crate aside; it is a behavior change that needs its own measurement.

Relation to #2207

Independent: both branches start from the same upstream commit and change this file. #2207's description mentions
this cycle. Each adds a static helper above GetBreakableInPath, so whichever merges second needs a one-hunk rebase
that keeps both helpers; the results above ran on that combination.

Toolchain

  • Linux GCC Distro Native (Linux Mint 22.3, GCC 13.3.0)

Linked Issues

The clear-breakable action took any breakable the path's hull trace hit,
props included, but its Update ends at once on a target that is not
IsAlive(), and CBaseProp::IsAlive() is always false. On a breakable
prop in the path (prop_physics_multiplayer, hp 50) the action started
and ended every bot update, about every 0.13 s, switching to the knife
and back each time while the bot walked on pushing the prop.

Start the action only on a breakable that passes the same intact test
Update uses. func_breakable and func_breakable_surf are unchanged: they
never leave LIFE_ALIVE. Marketa, 4 matches a build: 236 start/end cycles
on props before, 0 after; panes still broken (6 of 6, 1 of 1).
@sunzenshen

Copy link
Copy Markdown
Contributor Author

#2197 handles this scenario already

@sunzenshen sunzenshen closed this Oct 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant